Date: Sat, 8 Jan 94 04:30:06 PST From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #4 To: tcp-group-digest TCP-Group Digest Sat, 8 Jan 94 Volume 94 : Issue 4 Today's Topics: Extended KISS and SMACK specifications? (6 msgs) Farewell SUBSCRIBE What does this mean? Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri, 07 Jan 1994 11:13:25 -0500 From: "Louis A. Mamakos" Subject: Extended KISS and SMACK specifications? To: Lyndon Nerenberg > Do you work for Sun? This sounds like their reasoning for turning off NFS > UDP checksums: dump the error checking so we can make the benchmarks look > better. No, I don't for Sun, and I think that lack of UDP checksums on NFS RPCs was a really silly thing to do. The point I was trying to make is that the original intent of KISS was a simple, easy to implement way to get a host that has no direct radio interface to talk to a TNC. Sure, adding checksums or CRCs to frames is a good thing.. but ACKs that the frames has been transmitted? What next? My point is that if a problem needs to be solved, perhaps taking a step back and starting over would be better than trying to organically grow and extend a protocol that was never really intended to be whacked on like this. An example of this in the Internet world is SLIP being replaced by PPP for extended functions. louie wa3ymh ------------------------------ Date: Fri, 7 Jan 1994 09:56:55 -0800 (PST) From: Lyndon Nerenberg Subject: Extended KISS and SMACK specifications? To: "Louis A. Mamakos" On Fri, 7 Jan 1994, Louis A. Mamakos wrote: > The point I was trying to make is that the original intent of KISS was > a simple, easy to implement way to get a host that has no direct radio > interface to talk to a TNC. Sure, adding checksums or CRCs to frames > is a good thing.. but ACKs that the frames has been transmitted? What > next? And I agree with you in principle, however there are two blatently obvious features that are missing from KISS: link layer data integrity checks (aka checksums) and transmision notification (aka timer callbacks). The latter is very important for those running on conjested slow speed networks (HF and 1200 bps VHF). I feel that both are important enough that they overshadow any religious arguments concerning the name of the protocol. --lyndon ------------------------------ Date: Fri, 07 Jan 1994 17:19:53 -0500 From: "Brandon S. Allbery" Subject: Extended KISS and SMACK specifications? To: tcp-group@ucsd.edu In your message of Fri, 07 Jan 1994 09:56:55 PST, you write: +--------------- | On Fri, 7 Jan 1994, Louis A. Mamakos wrote: | > The point I was trying to make is that the original intent of KISS was | > a simple, easy to implement way to get a host that has no direct radio | > interface to talk to a TNC. Sure, adding checksums or CRCs to frames | > is a good thing.. but ACKs that the frames has been transmitted? What | > next? | | And I agree with you in principle, however there are two blatently | obvious features that are missing from KISS: link layer data integrity | checks (aka checksums) and transmision notification (aka timer | callbacks). The latter is very important for those running on conjested +--------------- There is also the point that amateur TCP/IP has enough problems getting established in existing packet communities without requiring special hardware on top of it. KISS and extended KISS are easy to add to existing TNCs, and KISS is already present in many of them, so a packeteer can experiment with TCP/IP without having to go buy a special comm card. Make that a requirement and you'll see fewer people willing to try out TCP/IP, and less interest in TCP/IP in the packet community. Before someone suggests that we run SLIP to a "SLIP TNC", remember that such a TNC must be rather more intelligent than current TNCs, and have more memory: it has to be a router, not merely a protocol converter. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca Do not taunt Happy Fun Coder. (seen on the Net...) ------------------------------ Date: Fri, 7 Jan 94 16:21 PST From: bruce@pixar.com (Bruce Perens) Subject: Extended KISS and SMACK specifications? To: "Louis A. Mamakos" Louie, Innocently I ask for a document and ignite some sort of policy discussion :-) . It's a bit late to argue the merits of extending KISS now. The firmware already exists in (probably) tens of thousands of TNCs, and NOS (at least WAMPES) uses it. The people who wrote it were doubtless too busy writing software and could not take the time to have an argument about it. Bruce -- Bruce Perens AB6YM Bruce@Pixar.com 510-215-3502 ------------------------------ Date: Fri, 7 Jan 94 16:05 PST From: bruce@pixar.com (Bruce Perens) Subject: Extended KISS and SMACK specifications? To: tcp-group@ucsd.edu Running serial links without error control in a high-RF environment is both Simple and Stupid. For me, it breaks above 4800 baud, probably because the PK-88 starts dropping characters. If I enable KISS checksums, the TNC does not transmit a garbage packet when errors happen. The only real way to keep it Simple without being Stupid is to junk the TNC and use something like an SCC or PI card that obsoletes KISS. Since nobody has been able to point out an extensions document. I'm going to use my AEA manual as a document for the extensions that aren't in SMACK. Bruce Perens -- Bruce Perens AB6YM Bruce@Pixar.com 510-215-3502 ------------------------------ Date: Fri, 7 Jan 94 16:40:28 PST From: myers@pongo.West.Sun.COM (Dana Myers ) Subject: Extended KISS and SMACK specifications? To: tcp-group@ucsd.edu > Subject: Extended KISS and SMACK specifications? > Date: Fri, 07 Jan 1994 17:19:53 -0500 > From: "Brandon S. Allbery" > > In your message of Fri, 07 Jan 1994 09:56:55 PST, you write: > +--------------- > | On Fri, 7 Jan 1994, Louis A. Mamakos wrote: > | > The point I was trying to make is that the original intent of KISS was > | > a simple, easy to implement way to get a host that has no direct radio > | > interface to talk to a TNC. Sure, adding checksums or CRCs to frames > | > is a good thing.. but ACKs that the frames has been transmitted? What > | > next? > | > | And I agree with you in principle, however there are two blatently > | obvious features that are missing from KISS: link layer data integrity > | checks (aka checksums) and transmision notification (aka timer > | callbacks). The latter is very important for those running on conjested > +--------------- > > There is also the point that amateur TCP/IP has enough problems getting > established in existing packet communities without requiring special hardware > on top of it. KISS and extended KISS are easy to add to existing TNCs, and > KISS is already present in many of them, so a packeteer can experiment with > TCP/IP without having to go buy a special comm card. Make that a requirement > and you'll see fewer people willing to try out TCP/IP, and less interest in > TCP/IP in the packet community. > > Before someone suggests that we run SLIP to a "SLIP TNC", remember that such a > TNC must be rather more intelligent than current TNCs, and have more memory: > it has to be a router, not merely a protocol converter. > > ++Brandon Well, Phil's original intent of KISS was to provide a bridge between current TNCs and plug-in adapters which he appears to have expected to become more prevalent by now. Reading the paper in the CNC plainly indicates this. However, history has not quite played out that Phil, and pretty much everyone else, expected. Plug-in packet interfaces are not the rage, and KISS has taken on a life quite different than the limited one Phil envisioned. The KA9Q IP suite was the motivation for KISS, but BBS software has embraced it, too, and the issues driving the extension of KISS can not be dismissed. Of course, Phil is far more capable of speaking for himself than I can speak for him, but I tend to believe KISS has grown beyond what he really expected. Therefore, I'm not sure it makes sense, today, to re-iterate the principles that drove the creation of KISS and prevent improvement of the protocol.... ------------------------------ Date: Fri, 7 Jan 94 17:17:49 MET From: gvdg@tophat.cdh.cdc.com Subject: Farewell To: gateways@mpg.phys.hawaii.edu Hello Folks, Here is my letter of goodby, As Control Data does not want to make use of my services (after being there 27 years) anymore , I do have to pull some plugs. One is the gateway. Others are the mail lists I am on. (this one). How I can keep a link to ucsd.edu to send my domain updates is also an unknown. Perhaps some other gateway i might reach from 44. net can be of use. Thanks all for having a wonderfull time on the net (with net/nos). 73's and till we meet again. (i am hunting for another job....but being 46 doesn't help in the market.) Regards, Gerard. PS, I was thinking of a nice speech but..... -- Internet: gvdg@cdc.com | Gerard J van der Grinten UUCP: gvdgpc!gvdg | Control Data Bv. Telephone: 0(+31)-15-153123 | Olaf Palmestraat 20 | 2616 LS DELFT Netherlands ------------------------------ Date: Fri, 7 Jan 94 10:04:00 -0600 From: tim.havens@drig.com (Tim Havens) Subject: SUBSCRIBE To: tcpgroup@ucsd.edu add telcom!wx2l!tcpgroup@apple.com ------------------------------ Date: Fri, 7 Jan 1994 18:57:25 -0800 From: karn@qualcomm.com (Phil Karn) Subject: What does this mean? To: steve@zero.com > Is there a reason not to have it compiled in so it doesn't > waist bandwidth or something? It sure looks that way, also Source quenches have long been controversial. One school thinks they're a bad idea because they add load to the network just when you can least afford it, and another thinks they can still be useful in managing congestion, especially when the congestion is only occurring at widely scattered spots. I tend to belong to the latter school. Of course, unless the sender does something with a source quench, then it really doesn't do anything at all. I have my TCP back its congestion window down to 1 packet, just as if it had timed out and retransmitted. This does throttle TCP down if there is real congestion. In a couple of places where I send source quenches, host unreachables are arguably more appropriate. An unresolved ARP state is one of them. I don't send them, though, because many non-compliant TCPs out there still abort their connections when they receive even a single unreachable. Phil ------------------------------ End of TCP-Group Digest V94 #4 ******************************